Do we actually need (or want) to cache ._users? If I do a new query, I want to start fresh. And instantiating Users() should be basically free.

Do we want to instantiate a new instance every time? The Users class is designed to fetch from the server once, and then use cached results for subsequent iterations.

There are pros and cons to fetching from the server every time.

We currently don't have any methods that mutate the server, but when we do, my thought is to invalidate the cache on methods that mutate (post, delete, put). This would trigger a fresh fetch on the next iteration.

Also, passing self to Users instead of the session and config seems odd. This makes client.users.client.users.client.users valid

If the goal is to reduce the boilerplate of passing two variables down to one, I would prefer creating a DTO object that wraps session and config. But, I still think that is overkill at this stage.

The Users class is designed to fetch from the server once, and then use cached results for subsequent iterations.

I think instantiating from Client every time gives you the behavior you want. If you (the SDK user) want to use the cached results, do something like all_users = client.users.find() and work with all_users as much as you want. But some actions you'll want to do will modify the collection on the server, and you'll want a way to refresh. So then you go to client.users again.

Also, passing self to Users instead of the session and config seems odd. This makes client.users.client.users.client.users valid

True, but IME it's useful to be able to get back to the original connection object from wherever you are in the API.

If the goal is to reduce the boilerplate of passing two variables down to one, I would prefer creating a DTO object that wraps session and config. But, I still think that is overkill at this stage.

Isn't Client already the object that wraps session and config?

I don't really have any strong opinion about how this happens. My only requirement at this stage is that there is some way to get information about the currently authenticated user from the v1/user endpoint. I need this information to be available in the OAuthIntegration Resource.

I'm fine with changing to approach to use DI instead if that's preferred. For example:

def OAuthIntegration(Resource):
  def __init__(self, current_user: CurrentUser[Resource]):
    ...
    
  def get_credentials():
    guid = self.current_user.get().get('guid')

True, but IME it's useful to be able to get back to the original connection object from wherever you are in the API.

session holds the connection here.

Isn't Client already the object that wraps session and config?

Yes, but circular references should generally be avoided.